1. Field of the Invention
Embodiments of the present invention relate, in general, to response based message systems and particularly to a bounding storage space at the source and the destination of response based message systems.
2. Relevant Background
The World Wide Web, also known as the Internet, has become a standard means by which to convey information and data. Using a standard protocol, two parties can convey information over vast distances inexpensively and efficiently. Hypertext Transfer Protocol (“HTTP”) is a communications protocol for the transfer of information widely used on intranets and the Internet.
Increasingly, business data processing systems, entertainment systems, and personal communications systems are implemented by computers across networks that are interconnected by internetworks (e.g., the Internet). The Internet is rapidly emerging as the system for distributing and exchanging data. Data exchanges support applications including electronic commerce, broadcast and multicast messaging, videoconferencing, gaming, and the like. In electronic commerce (e-commerce) applications, it is important to provide a satisfying buying experience that leads to a purchase transaction. To provide this high level of service, a web site operator must ensure that data is delivered to the customer in the most timely, usable, and efficient fashion.
The Internet is a collection of disparate computers and networks coupled together by a web of interconnections using standardized communications protocols. While most Internet access is currently performed using conventional personal computers and workstations, the variety of devices that access the Internet is growing quickly and projected to continue to grow. It is expected that a variety of appliances and devices within offices, businesses, and households will support Internet connectivity in the coming years.
The Internet is characterized by its vast reach as a result of its wide and increasing availability and easy access protocols. Unfortunately, the ubiquitous nature of the Internet results in variable bandwidth and quality of service between points. The latency and reliability of data transport is largely determined by the total amount of traffic on the Internet and so varies wildly seasonally and throughout the day. Other factors that affect quality of service include equipment outages and line degradation that force packets to be rerouted, damaged, and/or dropped. Also, routing software and hardware limitations within the Internet infrastructure may create bandwidth bottlenecks even when the mechanisms are operating within specifications. The variable nature of the quality of service (QOS) provided by the Internet has made development and deployment of database systems that leverage the Internet infrastructure difficult.
HTTP is a request/response standard between a client and a server. A client is the end-user, the server is the web site. The client making an HTTP request—using a web browser, spider, or other end-user tool—is referred to as the user agent. The responding server—which stores or creates resources such as Hyper Text Markup Language (“HTML”) files and images—is called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels. HTTP is not constrained to using Transmission Control Protocol (“TCP”) or the Internet Protocol (“IP”) and their supporting layers, although this is its most popular application on the Internet. Indeed HTTP can be implemented on top of any other protocol on the Internet, or on other networks. One deficiency of HTTP is that HTTP presumes a reliable transport without providing any such basis for that presumption.
In a typical HTTP transmission, an HTTP client initiates a request and establishes a TCP connection on a host. An HTTP server waits for the client to send a request message. Upon receiving the request, the server sends back a status line and a message of its own, the body of which is perhaps the requested file, an error message, or some other information.
To overcome the reliability deficiency of HTTP transmissions, a new standard entitled “Web Service Reliability Messaging” was created. Web Services Reliable Messaging describes a protocol that allows Simple Object Access Protocol (“SOAP”) messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. In other words, the ability to reliably send messages over an unreliable network.
SOAP is a protocol for exchanging Extensible Mark-up Language (“XML”) based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the web services protocol stack providing a basic messaging framework upon which abstract layers can be built.
FIG. 1 shows a high level system depiction of Web Services Reliable Messaging as is known in the prior art. In Web Services Reliable Messaging, an Application Source (“AS”) 110 wishes to reliably send messages to an Application Destination (“AD”) 160 over an unreliable infrastructure. To accomplish this, and AS makes use of a Reliable Messaging Source (“RMS”) 120 and a Reliable Messaging Destination (“RMD”) 140. The AS 110 sends a message to the RMS 120. The RMS 120 uses the WS-Reliable Messaging (“WS-RM”) protocol to transmit the message to the RMD 140. The RMD 140 delivers the message to the AD 160. If the RMS 120 cannot transmit the message to the RMD 140 for some reason, the RMS 120 must raise an exception or otherwise indicate to the AS 110 that the message was not transmitted. The AS 110 and RMS 120 may be implemented within the same process space or they may be separate components. Similarly, the AD 160 and RMD 140 may exist within the same process space or they may be separate components.
WS-RM specification deals with the contents and behavior of messages as they are being conveyed. How messages are sent from the AS 110 to the RMS 120, how they are delivered from the RMD 140 to the AD 160, whether messages are persisted on-disk or held in memory, etc. are not part of the WS-RM specification.
As implied, one issue is the persistence of a message by both the sender (AS in FIG. 1) and the recipient (AD in FIG. 1). Typically when a source sends a message, it first creates a copy of the message and stores that message in a persistent source. As is well known to one skilled in the relevant art, a persistent source or persistent memory, as it is sometimes referred to, is a memory source capable of retaining data absent a constant power source. Memory of this type establishes a state based on an input and then remains in that state, with or without power, until it is actively changed. Thus the copy of the message made by the source prior to sending the message can be recovered and resent should a loss or interruption of power occur during transmission. Similarly, the recipient of the message creates a copy of the message before it uses the content of the message. Thereafter a separate open channel is created to determine what stored messages must be maintained and which can be deleted. As the number of messages increase in volume so, too, must the number of channels to communicate what messages must be kept and which can be deleted. As message volume increases, such a duplicate process is inefficient and costly in terms of both bandwidth and storage capacity. These and other deficiencies of the prior art are addressed by embodiments of the present invention.